Статьи

В предыдущей статье мы начали говорить о моделях ветвления при работе с Git и рассмотрели модель Feature Branch Workflow. В данной статье мы рассмотрим еще одну популярную модель ветвления – Gitflow.

Данная статья является переводом англоязычной статьи из обучающих материалов Atlassian.

Модель ветвления Gitflow была впервые опубликована и стала популярной, благодаря статье Vincent Driessen. Она предполагает выстраивание строгой модели ветвления вокруг релиза проекта, которая дает надежную схему управления крупными проектами.

Gitflow отлично подходит для проектов, которые имеют спланированный цикл релиза. Эта модель не предполагает дополнительных понятий, кроме тех, что описаны для модели Feature Branch Workflow. Вместо этого она приписывает особые роли разным веткам и определяет, как и когда они должны взаимодействовать. Кроме feature-веток в ней используются отдельные ветки для подготовки, поддержки и записи релиза. Конечно, также необходимо эффективно использовать все преимущества Feature Branch Workflow: пул-реквесты, изоляция для изменений и эффективное сотрудничество внутри команды.

Gitflow использует собственный набор инструментов git-flow, который легко интегрируется с Git, добавляя новые команды Git.

При работе с Git важно выбрать подходящую модель ветвления, максимально отвечающую потребностям команды. Существует множество различных моделей. Например, Atlassian рассматривает 4 вида моделей. В этой статье мы рассмотрим модель Feature Branch Workflow.

Данная статья является переводом англоязычной статьи из обучающих материалов Atlassian.

Основная идея модели Feature Branch Workflow заключается в том, что вся работа над новой функциональностью должна производится в отдельной ветке, а не в ветке master. Такая инкапсуляция облегчает работу нескольких разработчиков над общей функциональностью в рамках одной кодовой базы. Также это значит, что нерабочий код никогда не попадет в ветку master, если процессы интеграции реализованы правильным образом и эффективно обеспечивают контроль качества.

Изоляция работы над новой функциональностью также позволяет эффективно использовать запросы на объединение кода (pull request, merge request), которые являются способом инициализации обсуждения изменений, созданных в ветке. Они дают другим разработчикам возможность одобрить функциональность перед интегрирацией в официальный проект. Или, если в процессе работы над функциональностью разработчик столкнулся с проблемой, он может создать запрос на объединение и спросить совета у коллег. Суть в том, что запросы на объединение позволяют участникам команды комментировать работу друг друга.

Модель Feature Branch Workflow можно эффективно использовать как базу для других высокоуровневых схем работы с Git. В модели Feature Branch Workflow в центре внимания – ветвление, это значит, что она является основной используемой моделью для создания веток и управления ими. Так, она обычно используется в моделях Gitflow и Forking Workflow для организации ветвления.

По мере проникновения контейнеров в продуктовые среды у системных администраторов и разработчиков возникает необходимость мониторинга текущих рабочих показателей контейнеров и сбора метрик для анализа. В этой статье вы сможете узнать, какие механизмы для решения этой задачи могут быть использованы при использовании Docker.

Данная статья является переводом англоязычной статьи из официальной документации Docker. В процессе перевода мы постарались упростить статью.

Данная статья является переводом англоязычной статьи Владислава Супалова.

В связи с последними релизами в мире Docker произошли некоторые изменения. В версии 1.12 в Docker Engine был интегрирован режим Swarm, в связи с чем появилось несколько новых инструментов. Среди прочего, теперь появилась возможность использовать Compose-файлы docker-compose.yml для создания стеков контейнеров Docker без необходимости устанавливать инструмент Docker Compose.

Теперь для этого есть команда docker stack, и она очень похожа на docker-compose. Сравните:

$ docker-compose -f docker-compose up

$ docker stack deploy -c docker-compose.yml somestackname

Обе команды создают все сервисы, тома, сети и все остальное, что определено в файлах docker-compose.yml. Почему получилось так, что возникли два очень похожих инструмента, которые выполняют одну задачу? Отличается ли docker stack от docker-compose? Зачем создали docker stack? Что следует учитывать, кроме синтаксиса?

Шаблон рабочей нагрузки серверов CI/CD существенно отличается от других типовых шаблонов нагрузки. Причина лежит в характере рабочей нагрузки, которую создают приложения, выполняющиеся на этих серверах. В рамках процессов CI/CD существует два основных типа рабочей нагрузки:

• сборка, тестирование и развертывание артефактов;
• выполнение развернутых сред тестирования для веток Git, коммитов и конфигураций.

Обычно лучше разделять эти нагрузки так, чтобы они выполнялись на разных серверах. Основная предпосылка в том, что рабочая нагрузка, создаваемая процессами сборки, стремится утилизировать максимальное количество доступных вычислительных ресурсов (CPU, IO) для быстрого выполнения задачи. Когда на том же сервере размещаются и развернутые приложения, разработчики должны применять ограничивающие политики для защиты развернутых окружений от нехватки ресурсов, вызванной чрезмерным использованием серверных ресурсов во время выполняения процессов сборки и тестирования.